It is helpful to quote the specification verbatim so that the intent is understood from the quoted context in the event that the specification changes.

Thank you for the suggestion.
I will implement the wording as it is except for one point - wouldn't it be better to use sycl_external attribute instead of SYCL_EXTERNAL macro which is not yet implemented?

I tend towards quoting the text verbatim. Readers are likely to be aware that the intent of the sycl_external attribute is to implement the SYCL_EXTERNAL macro; that was made clear in the documentation for the attribute.

These examples are all grammatically correct because the tokens form a valid attribute-specifier and are placed in a grammatically correct position in each declaration. The only part of the syntax that would be grammatically specific to sycl_external would be the syntax of its arguments; if it took any. I think it is reasonable to keep (invalid) examples like bar() that exercise arguments here since, if the attribute were extended to accept an argument, this would be the right place to validate them. I think these are good examples to test in this file:

[[clang::sycl_external()]] void bad1();
[[clang::sycl_external(,)]] void bad2();
[[clang::sycl_external(3)]] void bad3();
[[clang::sycl_external(4,)]] void bad4();

The a and b examples exercise appertainment and I think would best be placed in a sycl-external-attr-appertainment.cpp test.

The foo() example is redundant; similar declarations are validated by sycl-external-attr.cpp.

I suggest using "invalid" in place of "avoid" for consistency with other nearby diagnostics. Please keep the wrapping and indentation style consistent with nearby code.

The wrapping and indentation style was modified by git-clang-format tool, which surprised me! I'll revert it.

I don't think the namespace scoped example adds anything here, but I think it would be good to exercise a function template.

Add spacing to avoid potential merge conflicts or careless additions of additional RUN lines in the future.

For consistency and in case the default changes some day.

This is a good test. I suggest trying to keep the tests self-contained as much as possible so that they are easy to review without having to look elsewhere. A consistent naming scheme can help to avoid unintended reuse of symbols that can potentially affect test outcomes.

Other interesting internal linkage cases:

The attribute from the primary template is inherited by the specialization instantiated by the explicit template instantiation declaration. It could be argued that, because the explicit instantiation declaration names the symbol that causes the instantiated specialization to have internal linkage, a diagnostic should be produced here. However, other template shenanigans can produce similar results and would be difficult to diagnose well. I think we should ensure that a diagnostic is not issued for this case.

namespace { struct S6 {}; }
template<typename>
[[clang::sycl_external]] void func6() {}
template void func6<S6>();

In this case, the attribute from the primary template is not inherited by the specialization produced by the explicit specialization declaration. No diagnostic should be issued for this case. However, Clang doesn't implement the attribute inheritance semantics correctly (according to the standard), so if a diagnostic is issued, we should just add a FIXME comment and not worry about it.

namespace { struct S7 {}; }
template<typename>
[[clang::sycl_external]] void func7();
template<> void func7<S7>() {}

Here is another case. DPC++ does diagnose this one. https://godbolt.org/z/9E9aPn6eq

namespace { struct S8 {}; }
template<typename>
void func8();
template<> [[clang::sycl_external]] void func8<S8>() {}

Avoid blank lines between declarations that are part of the same test so that it is easy to see that they go together. Use line markers and references in expected diagnostics to avoid line length issues.

This test doesn't require a member function, but the presence of class D suggests that there is something specific to member functions here.

Validate a static member function too.

I assume these are intended to exercise the generic address space limitations. Let's add a comment to make that clear. I don't know if any of the target devices we expect to support lack support for the generic address space, so we might not be able to effectively test a positive diagnostic, but it is good to ensure no diagnostic for the common case.